In the realm of firewalls, a Trojan DLL and similar counterparts are a kind of trojan that leverages an authorized application program in order to cloak its own communication efforts. An authorized application program is one that the user has authorized the computer firewall to allow to communicate. Similarly, an unauthorized or unknown application program is not allowed to communicate. By this design, traditional Trojan EXEs are therefore blocked from communicating unless a user authorizes them.
Unlike Trojan EXEs, however, a trojan in a DLL form can easily bypass a firewall by leveraging an already authorized application program in order to cause it to be loaded into the address space (execution context) of the authorized application program. Once loaded, the Trojan DLL can unfortunately communicate under the shield of the authorized application program.
A Trojan DLL can use a number of methods in order to cause it to be loaded by an authorized application program. Table 1 illustrates some of such methods.
TABLE 11.The Trojan DLL can be copied over an existing DLL usedby the application program.2.The Trojan DLL can be registered as a loadable objectin place of, or in addition to, the existing DLL(s)used by the application program.3.The Trojan DLL can use Windows ® API functions causingit to be injected into the address space of theauthorized application program.4.The Trojan DLL can spoof an existing DLL used by theapplication program and/or run the authorizedapplication program from a different location.
It should be noted that there are additional ways by which a trojan can execute in the context of an authorized application program, without requiring a DLL.
Prior art firewalls have deployed several techniques to guard against such Trojan DLLs. For example, firewalls have been designed to limit the communication of authorized application programs to specific protocols and/or channels. Moreover, such firewalls have been configured to detect attempts to communicate using other protocols and/or channels. Unfortunately, the trojan can still communicate using the protocols and/or channels that are allowed. Moreover, limiting communication in the foregoing fashion requires considerable research into the protocols and/or channels used by the application program, which tend to change over time and based on how the application program is used.
Still yet, prior art firewalls have been designed to protect program modules belonging to the authorized application program from being overwritten by a trojan. For example, newer versions of Windows® include system file protection (SFP) which protects most required system components from alteration. Unfortunately, however, it can be difficult to identify program modules belonging to an application program, since program DLLs are typically loaded and unloaded based on what the user is doing and what other application programs are running. Moreover, most DLLs in use by an application program are not used for the purpose of communication. Many applications including Windows® itself include updating mechanisms that cause the firewall to detect and report modifications to a DLL, even though the modifications do not result in any unauthorized communication.
Further, previous firewalls are capable of identifying and signing or check summing the program modules belonging to an authorized application program, either at the time the application program is authorized, or at any time prior to a trojan gaining control. The firewall can then re-validate the program modules in the address space of the authorized application program whenever it communicates, ensuring that only known and valid program modules exist in the address space. Unfortunately, however, this technique still suffers from some of the drawbacks listed above.
Even still, prior art firewalls can restrict access to the Windows® registry to prevent trojans from modifying or creating new registrations. Some personal firewall systems implement a similar form of this protection. However, many application programs routinely modify and create registrations, and it requires considerable user intervention to decide what application programs to authorize. Also, this method only protects against case (2) above.
Also in the prior art are firewalls that can intercept the Windows® API functions used to inject a DLL into the address space of another process. Regrettably, intercepting Windows® API functions is nontrivial and discouraged. Moreover, many application programs routinely use these API functions for legitimate means.
Finally, firewalls of the prior art can require an authorized application program to be re-authorized if it is run from another location, to prevent it from being used to shield a Trojan DLL. Some firewalls even do this automatically. However, this method only protects against case (4) above.
Unfortunately, as mentioned hereinabove, the foregoing prior art concepts fail to adequately prevent unauthorized program modules from communicating. There is thus a need for an improved technique of preventing viruses such as trojans from proliferating via communicating unauthorized program modules.